Date: Thu, 21 Jan 93 04:30:02 PST 

From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu> 
Errors-To: Packet-Radio-Errors@UCSD.Edu 

Reply-To: Packet-Radio@UCSD.Edu 

Precedence: Bulk 

Subject: Packet-Radio Digest V93 #20 

To: packet-radio 


Packet-Radio Digest Thu, 21 Jan 93 Volume 93 : Issue 20 


Today's Topics: 
BayComm Software 
High Speed Backbones? (2 msgs) 
High Speed Backbones in CT 
How to learn about packet? (2 msgs) 
KA9Q NOS - saving screen output 
PK-232 vs MFJ1278 (opinions wonted) (2 msgs) 
Ramsey IBM PC packet TNC any good? (2 msgs) 
subscribe 
TCP/ax25 for Sun sparc help???? 
Why not? 
Working KA9Q (PPP/C-SLIP) for Unix? 


Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu> 
Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Packet-Radio Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: Wed, 20 Jan 1993 18:31:11 GMT 

From: dog.ee.lbl.gov!overload.1lbl.gov!agate!spool.mu.edu!uwm.edu!linac!tellab5! 
jwa@network.UCSD.EDU 

Subject: BayComm Software 

To: packet-radio@ucsd.edu 


Can someone E-mail me a copy of the BayComm software. I can't FTP 
from this site. I have uudecode and pkunzip capabilities. 


I shure would appreciate it! Thanks! 


Jack Albert Fellow Radio Hacker 
Tele (708) 512-7854 


Tellabs, Inc. FAX (708) 852-7346 

4951 Indiana Ave. jwa@tellabs.com 

Lisle, IL 

60532 Do things really go better with Coca-Cola? 


Date: 20 Jan 93 15:28:35 GMT 
From: news-mail-gateway@ucsd.edu 
Subject: High Speed Backbones? 
To: packet-radio@ucsd.edu 


If most of the users in an area are 1200 bps, as is the case everywhere 
in the world right now, then 9600 bps links are more than adequate 
between nodes and services (services being BBSs, callsign databases, 
tcp routers, etc). 


When the 9600 bps users (users, as opposed to network infrastructure) 
become a significant segment of the population, then the links between 
nodes and services have to be higher speed to avoid congestion. The 
next logical step above 9600 bps is 56kb. 


It is clear to me that simplex packet can only work in very small cells 
where every user can hear every other user. Unless you design a 
network in that way, the collision-retry nature of the channel will 
guarantee throughput in the slow snail category. 


A full-duplex repeater solves that problem by completely eliminating 
the hidden-terminal problem, and thus resolves a goodly amount of the 
collision congestion. It also avoids the incredible waste of bandwidth 
that digipeaters and net/rom nodes represent. 


One high-level repeater can serve a very large area. However, in my 
view, it is better to have small regions (perhaps a town or community) 
served by a low-level repeater through which all local packet stations 
would communicate, coupled with a network interface that connects to a 
central multi-community high-level repeater used only for the regional 
systems to communicate. 


Making the community repeaters 1200 bps (and dual-speed with 9600 bps 
as well) means that the users don't have to do much except learn how to 
operate the offset switch on their radios. Making the central hub 
repeater operate at 9600 bps ensures that there is sufficient bandwidth 


for inter-regional communications, and it resolves the difficulty of 
making the 9600 bps stuff work by leaving it to the technical teams who 
build the repeater. 


Yes, it's a significant investment in network infrastructure. Perhaps 
more important is that it's a significant investment in cooperation, 
which hams have never been real strong on. But it will work WELL, far 
better than the ham packet networks in place in 90% of the world now. 


I think we ought to try it. If I have the chance to re-engineer the 
San Diego metro network, this is the way I'm going to go. 


Sometimes you can't see how to do things right until you've tried other 
methods. But that's one of the biggest parts of ham radio: experimentation. 
- Brian 


Date: Wed, 20 Jan 1993 17:18:20 GMT 

From: dog.ee.lbl.gov!overload.1lbl.gov!agate!usenet.ins.cwru.edu!gatech!emory! 
kd4nc!ke4zv! gary@network.UCSD.EDU 

Subject: High Speed Backbones? 

To: packet-radio@ucsd.edu 


In article <93018.142422PJC130@psuvm.psu.edu> <PJC130@psuvm.psu.edu> writes: 
>We are looking to install a backbone system around the SW Pa area. What 
>I've seen of the TexNet system is OK, but we would like to go > 9600 for the 
>backbone. (19200 is OK, 56K is preferred). 

> 

>One of the ideas that we have is that each point to point link is on its own 
>channel (multiple transceivers), another is that there is only one 
>transmitter per site, but multiple receivers. In either case, we certainly 
>need more than two ports per node. 

> 

>As ease of use (user transparency) is very important, a multiple NET/ROM or 
>TheNet hookup is not acceptable. 

> 

>Any ideas? 


Hubs with multiple receivers and a single transmitter can be useful 
when dealing with a user base. This is a technique used by AMSAT 
with the Pacsat birds. However, it makes network topologies and 
frequency reuse plans really complicated. Dedicated, full duplex 
backbone links are best, with a frequency reuse plan that alternates 
channel pairs in a cellular layout. This means that a switch needs 
at least 3 ports. One for neighbor left, one for neighbor right, 

and one for the user LAN. A Kantronics Data Engine is suitable for 
this kind of network tap. At a site where several trunks are hubbed, 


however, you really need a PC with multiple dedicated DMA capable 
cards, like the Gracillis cards. Running a switch optimized version 
of KA9Q, these can handle 5 or more ports. 


I wrote the mulport code in early versions of KA9IQ to make the 
system look simple to users. To them it looks like a flat digi 
network all operating on the same channel. They use normal digi 
strings and the system routes their packets, on a packet by packet 
basis, to the proper port for forwarding. Thus they don't have to 
know anything about frequency pairs or speed changes. All they 
needed to know was a digi path list. Now that's mostly obsolete 
thanks to the Netrom support in later versions of the code. The 
user sees what looks like a normal Netrom network and again has 
all the implementation details hidden from him. The user running 
TCP/IP has it even better. He doesn't have to know anything but 
the target host's name to use the network. Keeping the network 
transparent to the user is very important if naive users are 

to be supported. Hiding routing decisions in the switches means 
that users don't have to depend on ad hoc routing tricks that 

may change over time. As a switch maintainer, you can change 

the way the network is configured at will while still keeping 

it looking the same to a user. 


Gary 

Gary Coffman KE4ZV 
Destructive Testing Systems 
534 Shannon Way 
Lawrenceville, GA 30244 


You make it, 
we break it. 
Guaranteed! 


gatech!wa4mei! ke4zv! gary 
uunet!rsiatl!ke4zv! gary 
emory!kd4nc!ke4zv! gary 


Date: 20 Jan 93 16:20:19 GMT 

From: news-mail-gateway@ucsd.edu 
Subject: High Speed Backbones in CT 
To: packet-radio@ucsd.edu 


Could anyone out there give me as much info about the TCP/IP Network 
in the CT area?? 


-Nick KDILR 
nick@ccsi.com 


Date: Wed, 20 Jan 1993 16:58:43 GMT 
From: dog.ee.lbl.gov!overload.1lbl.gov!agate!usenet.ins.cwru.edu! gatech!emory! 


kd4nc!ke4zv! gary@network.UCSD.EDU 
Subject: How to learn about packet? 
To: packet-radio@ucsd.edu 


In article <8793@news.duke.edu> jbs@ee.egr.duke.edu writes: 

>In article <14JAN93.16332787@nauvax.ucc.nau.edu> cvm@nauvax.ucc.nau.edu writes: 
>>Can anyone recommend a good book or two (or other source of info) about packet. 
>>I would like a good introduction/overview and some more details and technical 
>>information. For example: I would like to know the details of the AX.25 
>>protocol. 

> 

>I can name a book that you should *xnot*x waste your money or time on. 

> 

>*DON'T BUYx "PRIME: Packet Radio is Made Easy" (published by MFJ). 

> 

>I picked up this piece of trash at a hamfest and am absolutely amazed that 
>MFJ (or any company!) would want its name attached to such bad writing. 

>It's obvious that no proofreader ever laid an eye on the text before it 

>went to press. Organization is poor; the author wanders aimlessly from one 
>topic to another with little linkage between topics. Information oscillates 
>from fuzzily vague to MFJ-specifically detailed. There is no indication on 
>the cover or in the introduction that 80% of the information in the book is 
>specific to MFJ TNCs and software (neither of which I possess); if you did 
>buy MFJ equipment the book might be marginally more helpful to you. 


This is a Buck Rogers book. Buck's the CQ packet editor, and his writing 
is of CQ quality. :-) He writes the way he talks, in great volumes and 
with little sense of grammar or spelling. 


Buck is highly opinionated, and his opinions change daily. :-) 

The hookup information he gives is largely correct, but the 

quaint ideas he has on networking and network services are best 

taken with a large grain of salt. This is especially true in older 
editions. He has progressed(?) from championing digis, to Netroms, 

to Rose, and finally he's now asking questions on how to setup TCP/IP. 


He has enormous stores of enthusiasm, and he's a real doer. 
Reading his book gives you insight into the typical amateur's 
approach to packet. He championed the C64 long after it was 
dead and is just now moving into commodity PCs. His model 

of packet is as an interactive keyboard to keyboard service. 
Don't use this book as a definitive text on networking, or 
network services, but it is a valuable text for gathering 
insight into the ways real amateurs are using packet radio 
and to the obstacles developers of real networks face. 


Gary 


Gary Coffman KE4ZV | You make it, | gatech!wa4mei!ke4zv! gary 
Destructive Testing Systems | we break it. | uunet!rsiatl!ke4zv! gary 
534 Shannon Way | Guaranteed! | emory!kd4nc!ke4zv! gary 
Lawrenceville, GA 30244 | 


Date: Wed, 20 Jan 1993 20:03:06 GMT 

From: sun-barr!cs.utexas.edu! zaphod.mps.ohio-state.edu!sdd.hp.com! 
hpscit.sc.hp.com!hplextra!hpfcso!hplvec!tcline@ames.arpa 

Subject: How to learn about packet? 

To: packet-radio@ucsd.edu 


In rec.radio.amateur.packet, tcline@hplvec.LVLD.HP.COM (Ted Cline) writes: 
> In rec.radio.amateur.packet, cvm@nauvax.ucc.nau.edu writes: 

> 

> For example: I would like to know the details of the AX.25 protocol. 

> 


> weeeweew nee een eee ewww ewww ewww eww ww ww ew eww ew ew eww ew eww ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ee ew = 
> Chris Michels -- Systems Programmer cvm@nauvax.ucc.nau.edu 

> Northern Arizona University -- Flagstaff, AZ cvm@nauvax.bitnet 

> Phone: (602) 523-6495 N7YIU 


I have uploaded the "AX.25 Amateur Packet-Radio Link-Layer Protocol, 
Version 2.0 October 1984" specification as ax25.doc in /hamradio/packet/ 
on ucsd.edu . If you have problems getting the file, I'll be pleased to 
email it to you. 


If you have Internet mail but not FTP, try the FTP mail server: senda 
mail message with the subject "help" and a single message line "help" to 
ftpmail@decwrl.dec.com. 


Ted Cline, NORQV 


VV VV VV VV VV VV VV VV VV VV WV 


I also offer to email any combination of the following files: 


42024 bytes, Dec 8 13:06, FAQ_HAM9212 = rec.radio.amateur.misc FAQ 

14055 bytes, Jan 4 21:46, FAQ_PACKET rec.radio.amateur.packet FAQ 

11433 bytes, Aug 11 17:37, PACKET.TUT = A "packet tutorial" (from 
PACKET. ARC) 


Ted Cline, NORQV VXI Systems Division 
ted_cline@hpisla.lvld.hp.com Hewlett-Packard, M/S CU-326 
tcline@hpislx.1lvld.hp.com 815 14th Street SW 


VOICE: (303) 679-2352 P.O. Box 301 


FAX: (303) 679-5971 Loveland, CO 80537 USA 


Date: 21 Jan 93 00:17:30 GMT 

From: munnari.oz.au!bunyip.cc.uq.oz.au!uqcspe! thrip! turner@uunet.uu.net 
Subject: KA9Q NOS - saving screen output 

To: packet-radio@ucsd.edu 


Does anyone know of a version of KA9Q NOS which will allow the 
output to the PC screen (eg. hop check tracing, icmp status) to be 
redirected to a file? 


I am helping to get NOS set up for teaching purposes and 

want to be able to print out the screen info. I am 

currently running JNOS105.EXE which is KA9Q NOS version 

911229, Johan Reinalda WG7J/PA3DIS on 2 XT's. I have found the 
trace command useful as it allows tracing to be stored 

in a tracefile, but am wondering if any other commands 

can do this or any other versions of NOS. 


Thanks in advance for any help. 


Margaret Turner email: turner@cs.uq.oz.au 
Computer Science Department fax: +61 7 365 1999 
University of Queensland 

Australia 4072 


Date: 20 Jan 93 17:21:40 GMT 

From: news-mail-gateway@ucsd.edu 

Subject: PK-232 vs MFJ1278 (opinions wonted) 
To: packet-radio@ucsd.edu 


Hi all, 


Some time ago I decided to by new all modes TNC. After short searching 
it looks there are only to models to consider: PK-232 and MFJ-1278. 
There is very hard to choose especialy that it will not cost a couple 
of bucks... I am not very experienced on this field so I do rely on 
opinions of other packet friends. 

I tryed to compare PK and MFJ by myself but it seems to be difficult. 
Here are some remarks: 


Prices are easy to compare. Well, Pk-232 is about 70 $ more expensive then 
MFJ-1278. Let's try to find reasons of it. 


There are of course a lot of PK's advantages which I think result from a long 
presence of AEA on a market (14 years!). There is very good service support, 
long list of distributors, well developed user friendly software (with some 
exclusive commands). AEA also takes care of easy to operate front panel 
design, all necessary cables and connectors are always included. And the most 
important. There are over 50 000 PK in use around the world. It looks like a 
standard... 


We all apreciate these features but I think the most important are technical 
differences. 

As we all know good selectivity is what we need when chasing DX in poor 
conditions. 

Here are two descriptions. Which one is right, maybe both? If both which one 
unit is better? Maybe I am trying to compare here an elephant and 

a toothbrush??? 


AEA: 

"... The PK-232 has no compromise VHF/HF/CW modem with eight pole Chebyshev 
bandpass filter folowed by a limiter discriminator with automatic treshold 
correction. (...) can be configured for optimum performance with different 
types of signals. ; 

"... One multi-mode contoller offered by another (probably MFJ) uses no input 
filtering on any mode. e 

"... While another manufacturer does offer selectable modem setings for 
different types of signals in their multi-mode controller, shortcuts in modem 


design limit the filter's performance. 2 


And MFJ: 

"... MFJ-1278 is the only multi-mode with a true DCD circuit. This dramatically 
reduces sensitivity to noise and dramatically increases completed QSOs. er 
"... Tests in Packet Radio Magazine prove the modem used in the MFJ-1278 


copies HF packet more accurately than all other modems tested. 
Looks great but there could be only one THE BEST! Any opinions welcome! 


PK offers exclusive Packet Lite and mailbox which can be accesed in AMTOR as 
well as packet. But PK-232 does not offer SSTV. AEA asserts that this type 
of modems is not able to provide satisfactory SSTV performance. They advise 
to buy separate modem... 

Is there anybody who can tell something about MFJ-1278's SSTV? 


I know that high speed modems can be conected to PK-232 but what about MFJ? 
Is there any way or possibility to connect PSK modem to one of these units? 


There are a lot of PK-232 users but I want to consider opinions of MFJ-1278 


defenders also. Any advise can help me to make up my mind... 
Thank you in advance, 


73 de Greg, SP1WSN 


Date: Thu, 21 Jan 1993 03:42:31 GMT 

From: dog.ee.lbl.gov!overload.1lbl.gov!agate!spool.mu.edu!uwm.edu!cs.utexas.edu! 
hermes.chpc.utexas.edu!news.utdallas.edu! feenix.metronet.com! 
marcbg@network.UCSD.EDU 

Subject: PK-232 vs MFJ1278 (opinions wonted) 

To: packet-radio@ucsd.edu 


In article <9301201751.AA22332@ucsd.edu> GREG@PLSZUS11.BITNET writes: 
>Hi all, 

> 

>Some time ago I decided to by new all modes TNC. After short searching 
>it looks there are only to models to consider: PK-232 and MFJ-1278. 
>There is very hard to choose especialy that it will not cost a couple 
>of bucks... I am not very experienced on this field so I do rely on 
>opinions of other packet friends. 


My money is on the PK232. I've owned both, and the PK232 is far superior 
on CW reception (not what you may use it for, but you never know). Also, 
AEA has a history of continually updating the firmware for the unit since 
it came out. Not the MFJ doesn't, but I've been less than impressed with 
my dealing with the MFJ customer service department. Also note that 
Kantronics makes an all-mode (KAM) which you should also consider. It's 
smaller in size than the PK232. I don't have experience with the KAM but 
I am very impressed with my KPC4 dual port modem. Good luck and happy 
hunting, hope this helps. 

Marc Grant, N5MET 

marcbg@feenix.metronet.com 

call 146.88 when in Dallas, Texas! 


Date: Wed, 20 Jan 1993 21:48:12 GMT 

From: pacbell.com!sgiblab! zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu! 
linac!att!att!allegra!rfc@network.UCSD.EDU 

Subject: Ramsey IBM PC packet TNC any good? 

To: packet-radio@ucsd.edu 


At a hamfest last weekend I saw, at the Ramsey electronics table, a TNC 
kit. This TNC is designed to connect (and get its power from) the serial 
port (think it was the serial port, it's been a few days ago!). "No 


adjustments, all feeqs are crystal referenced", "platform for 'poor man's 
packet'". price: $60. connects to radios and HTs. 


Anyone buy and build this thing? Any good? for the money? 


Date: Thu, 21 Jan 1993 04:23:25 GMT 

From: think.com!yale.edu!ira.uka.de!sol.ctr.columbia.edu!news.cs.columbia.edu! 
popovich@ames.arpa 

Subject: Ramsey IBM PC packet TNC any good? 

To: packet-radio@ucsd.edu 


> At a hamfest last weekend I saw, at the Ramsey electronics table, a TNC 
> kit. This TNC is designed to connect (and get its power from) the serial 


> port (think it was the serial port, it's been a few days ago!). "No 
> adjustments, all feeqs are crystal referenced", "platform for 'poor man's 
> packet'". price: $60. connects to radios and HTs. 


Not to sound like a Clueless Appliance Operator(TM), but why take the 

trouble to assemble a kit when you can buy what sounds like the same 

thing from Tigertronics for about the same (actually, a few $$$ LESS)? 
-Steve 


Date: 20 Jan 93 20:46:10 GMT 
From: news-mail-gateway@ucsd.edu 
Subject: subscribe 

To: packet-radio@ucsd.edu 


subscribe 


Date: 20 Jan 93 17:49:41 GMT 

From: dog.ee.lbl.gov!overload.1lbl.gov!agate!spool.mu.edu!uwm.edu!linac!att!mcdchg! 
laidbak!newsserver.pixel.kodak.com! kodak! eastman!isctssl!braun@network.UCSD.EDU 
Subject: TCP/ax25 for Sun sparc help???? 

To: packet-radio@ucsd.edu 


Hi, we're trying to get ax25 running on a sparc station. we 

have a copy of the ax25 for the sun (written by a ve6) installed. 
Pings to get transmitted. etherfind sees the packets coming 

and going. the packets look good going on the radio side both to 
and from the station. the problem is that the interface to 

the window that we're working from (originating the ping) does 
not get any responses. It seems as though the low level routines 


see the packets, but they never make back to the sun window for 
display. We're running 4.2 release. Thanks for any pointers, we 
are a little stumped at the moment. We really need a working ax25 
interface on our sun, and we'd really like to do IP after 

that. So any help would be greatly appreciated. I have also 

sent this to the tcp mail group. 

Curtis Braun (curtis@computronics.com) (n2hkd) 

Computronics, POBOX 1002 Fairport,NY 14450 

Guest@Digital Telstar,Network Operations Center Kodak 


Date: 20 Jan 93 14:11:15 GMT 

From: swrinde! gatech!darwin.sura.net!paladin.american.edu!news.univie.ac.@!hp4at! 
mcsun!sunic!lunic!eru.mt.luth.se!enterpoop.mit.edu!hri.com!spool.mu.edu! 
sol.ctr.columbia.edu!destroyer!wsu-cs! 

Subject: Why not? 

To: packet-radio@ucsd.edu 


Why doesn't someone get a one way feed going to this newsgroup and then 
moderate it so that responses can go through a validated gateway? 


swood 


All Month Rabbit and Crow are legal to hunt all month in Michigan 
Current Michigan Canada Goose special late season still open 
(Southern Michigan Game Management unit only w/stamp) 
<<<<<< Only nine months until bow season!!! >>>>>> 


Date: Wed, 20 Jan 1993 22:49:48 GMT 

From: newsgate.watson.ibm.com! yktnews2.watson.ibm.com!yktnews!admin!aixproj! 
uri@uunet.uu.net 

Subject: Working KA9Q (PPP/C-SLIP) for Unix? 

To: packet-radio@ucsd.edu 


Hello, 
I'm trying to find a working port of KA9Q to 
Unix for a month now... I need it to support 


SLIP (hopefully with compression), PPP and 
AX25 (of course :-). 


I've seen "unixnet.cpio.Z" from ucsd.edu: it's nice, 
but extremely limited. And it's dated 1989/1990... 
So I made sure it compiles fine, and doesn't crash 


when invoked, but since it doesn't support PPP and 
C-SLIP, it won;t help me greatly... 


"nosunix-all.tar.Z" from <don't remember> seems to be 
a full-blown port, BUT... I can't get it running! It 
barely compiles (after several fixes), and then I've 
no way to debug it, it simply crashes with memory 
fault immediately after being invoked... I'm not 

very skilled with GDB, and it's too big for DBX. 


I'm trying to do this on AIX/PS2 v.1.3 and on ESIX 
Rev.D (Unix SysV.3.2/386)... 


Any help is APPRECIATED! 


Regards, 
Uri. uri@watson.ibm.com 
<Disclaimer> 


Date: Wed, 20 Jan 1993 22:29:00 GMT 

From: ucselx!sol.ctr.columbia.edu!howland.reston.ans.net!spool.mu.edu! uwm.edu! 
uucp.mr.med.ge.com!rdsunx.crd.ge.com!dssv01! kennykb@network.UCSD.EDU 

To: packet-radio@ucsd.edu 


References <1j]9hqcINN9rf@matt.ksu.ksu.edu>, 
<1993Jan16.201038.1158@sbcs.sunysb.edu>, <1993Jan18.003912.26961@qualcomm. com> 
Reply-To : kennykb@crd.ge.com 

Subject : Re: CDMA Packet Radio 


In article <1993Jan18.003912.26961@qualcomm.com>, karn@servo.qualcomm.com (Phil 
Karn) writes: 

In article <1993Jan16.201038.1158@sbcs.sunysb.edu> rick@cs.sunysb.edu (Richard 
Spanbauer) writes: 

> The main hitch with CDMA (code division multiple access) is that 

> the amateur radio service is allowed to use only three spreading 

> codes. Is there work being done towards relaxing the regulations 

> on use of spreading codes? 


One of those polynomials gives a spreading sequence that's 524287 
chips long. How well can we implement CDMA using different positions 


in that spreading sequence? 


73 de ke9tv/2, Kevin KENNY GE Corporate R&D, Niskayuna, New York, USA 


Date: 20 Jan 93 23:05:47 GMT 
From: eram!dave@midway.uchicago.edu 
To: packet-radio@ucsd.edu 


References <1j9hqcINN9rf@matt.ksu.ksu.edu>, 
<1993Jan16.201038.1158@sbcs.sunysb.edu>, <1993Jan18.003912.26961@qualcomm. com> 
Subject : Re: CDMA Packet Radio (WAS Re: Who do repeater coordinators represent?) 


In article <1993Jan18.003912.26961@qualcomm.com>, 
karn@servo.qualcomm.com (Phil Karn) writes: 


[ USA Amateurs can use only three spreading codes ] 

| I'm sure if there was a real need to change the rules, the FCC would 

| be willing to change them. There's an STA in existence right now 

| that waives this requirement. 

As an aside, there are no restrictions whatsoever on the use of SS 
technology in Australia (except being "wide band" it must be > 420 MHz). 


Dave Horsfall (VK2KFU) VK2KFU @ VK2RWI.NSW.AUS.OC 
dave@esi.COM. AU ...munnari!esi.COM.AU! dave 


Date: Wed, 20 Jan 1993 13:26:42 GMT 
From: sdd.hp.com!ncr-sd!ncrcae!ncrhub2!ciss!law7!jra@network.UCSD.EDU 
To: packet-radio@ucsd.edu 


References <93018.142422PIJC130@psuvm.psu.edu>, <C13x9L.MCC@srgenprp.sr.hp.com>, 
<1jhq8tINNadc@network.ucsd.edu> 
Subject : Re: High Speed Backbones? 


brian@ucsd.edu (Brian Kantor) writes: 


>Were I to do the San Diego Metro net over again, I'd put a single packet 
>9600 bps repeater up on a central location, and have all the outlying nodes 
>and services connect through it. 


This is what we're in Dayton with the 19.2 repeater. It provides the 
"backplane" for the other services to connect to. Rather than upgrade 
speed (for right now) our plans are to add a second repeater when the 
load is high enough to justify it -- we'll put users on one repeater 
and servers on the other. 


>Later, when there are more than two 9600 bps USER stations on the air in 


>town, we'd upgrade the repeater to 56kb. 


Given the way folks are not rushing to embrace a solution that's about 
as close to "plug and play" as it gets, I don't anticipate we'll need 
the second repeater for a couple of years... 


>Simplex packet is so difficult to make work properly*x that it's really 
>not worth trying. 


It's worth noting the the switch to a new baud rate/frequency/band is 
the ideal -- and probably the only -- time to implement a network like 
this and have some chance of getting it to work. Once users have 
settled into the simplex-"helped"-by-digi mode, inertia will make it 
almost impossible to change to a network that works. 


John 
John R. Ackermann, Jr. Law Department, NCR Corporation, Dayton, Ohio 
(513) 445-2966 John. Ackermann@daytonoh.ncr.com 
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